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(57) Abstract: Selective revocation of software components using a key hierarchy in a content protection system. A content distrib- 
utor creates a content voucher root key, a content voucher signing key, one or more component root keys, and a content voucher. A 
component vendor creates a vendor root key, a component class key, a component version key, and an object voucher. The content 
voucher, object voucher and associated software component for processing content may be communicated to a content user system. 
The keys are used to sign each other in a novel hierarchical arrangement to provide for determination of integrity and authenticity of 
software components distributed by the component vendor for use on the content user system. The components may be implicitly 
authorized by the content distributor for use with selected content as a result of the relationships between the keys in the key hierar- 
chy. Revocation of components may be implemented by inserting a revocation list into the content voucher. The revocation list may 
be checked prior to allowing access to content. Selective revocation of component versions, classes of components, and component 
vendors may be supported. 
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Method of Revoking 
Software Components in a Loosely 
Coupled Content Protection System 

5 

BACKGROUND 

1. FIELD 

10 The present invention relates generally to content protection in computer 

and consumer electronics systems and, more specifically, to revoking 
authorizations for software components used to render digital content. 

2. DESCRIPTION 

15 Physical objects such as compact disks (CDs) or cassette tapes holding 

entertainment content provide some measure of their own security simply by 
virtue of the fact that playback of the content is tied to having the physical 
object present. If one makes a copy (such as by recording music from a CD 
onto a cassette tape), the quality of the content is degraded. If one wants the 

20 highest quality content, one must buy or otherwise obtain an original product. 
The content distribution industry made it convenient for customers or users to 
have access to content by making it widely available at high-traffic consumer 
locations such as record and video stores, malls, and major discount stores. 
Presently, business to consumer electronic commerce, especially in the area of 

25 entertainment content, is growing rapidly on the World Wide Web (WWW) of 
the Internet. The proliferation of connected personal computers (PCs) and 
other Internet access devices, the growing bandwidth of the Internet, and better 
compression techniques are making it possible for content owners to take 
advantage of the Web as a place to offer digital content for sale and 

30 distribution. Many businesses are also increasingly using the Internet as a 
means to distribute confidential documents, images, video presentations, 
training and other digital content to employees at geographically dispersed 
locations. 
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Thus, the distribution of digital content over the Internet is increasing. 
With the increasing use of the Internet to buy, sell, or send music, video, 
documents, images, and other copyrighted or confidential content in digital 
form comes the need to protect that content from unauthorized use once it is 
5 outside the control of the publisher or distributor. Once a user has acquired 
digital content, the publisher needs to ensure that the usage rights of the 
content are respected. Since digital rights management (DRM) in 
computerized systems is typically enforced through software mechanisms, it is 
important that the software's integrity be checked before content is played 
10 back. Also, it is important to ensure that the playback mechanism is authorized 
by the content owner and that the security software itself has not been 
tampered with. . 

One existing technology applicable to digital content protection includes 
a public key infrastructure (PKI). A PKI enables users of an unsecure public 

15 network such as the Internet to securely and privately exchange data through 
the use of a public and private cryptographic key pair that is obtained and 
shared through a trusted authority. A PKI provides for digital certificates that 
can identify individuals or organizations and directory services that can store, 
and when necessary, revoke them. A PKI assumes the use of public key 

20 cryptography for authenticating a message sender or encrypting and decrypting 
a message. A PKI typically consists of a certificate authority (CA), a 
registration authority (RA), one or more directories where the certificates (with 
their public keys) are held, and a certificate management system. The CA is a 
trusted entity that issues and verifies digital certificates. A digital certificate is 

25 an electronic document or file that establishes an entity's credentials when 
doing business or other transactions on the Web. The certificate might include 
the public key or information about the public key, as well as other information, 
such as a name, serial number, expiration dates, and a digital signature of the 
certificate authority, so that a recipient can verify that the certificate is 

30 authentic. Digital certificates may be kept in registries so that authenticated 
users can look up other users' public keys. A RA is an entity that acts as the 
verifier for the certificate authority before a digital certificate is issued to a 
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requester. One use of a digital certificate is as an authorization certificate. A 
CA may delegate some form of authority to a key being signed. For example, 
a bank could issue an authorization certificate to a customer indicating that a 
particular key may be used to authorize withdrawal of funds from a specific 
5 bank account. 

Another technology applicable to content protection is code object 
signing. Various existing systems have implemented digital signatures for code 
objects, such as Authenticode, and Java Applet Certificates. Object signing 
uses techniques of public key cryptography to let users get reliable information 

10 about code the users may download from the Internet. When a code object is 
signed with a valid digital signature, a system may identify the signer and 
detect tampering with the code object. One approach to detection of tampering 
is described in a pending patent application entitled "Method and Apparatus for 
Integrity Verification, Authentication, and Secure Linkage of Software 

15 Modules," Serial No. 09/109,472, assigned to the assignee of the present 
invention. 

Previous attempts to safeguard Internet-distributed content at the user 
site using a PKI and/or code object signing have met several challenges. 
Solutions have been too costly to deploy and maintain, digital content had to 

20 be protected even while it was rendered, and most security solutions eventually 
need to be renewed. While some protection schemes exist for safeguarding 
digital content at the content creation and distribution phases, schemes for 
protecting content at the user site have been problematic. What is needed is a 
new software security system that acts on behalf of the content owner to 

25 ensure the integrity of software, to assert copy control mechanisms, and to 
ensure that only legitimate users have access to content, all without 
compromising an enjoyable user experience. Thus, new approaches to 
protecting content on the client or user system are needed. 

30 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The features and advantages of the present invention will become 
apparent from the following detailed description of the present invention in 
5 which: 

Figure 1 is a diagram of an architecture of a key management and 
content protection system according to an embodiment of the present 
invention; 

10 Figure 2 is a diagram of a key hierarchy according to an embodiment of 

the present invention; 

Figure 3 is a diagram of an alternate view of a key management and 
content protection system according to an embodiment of the present 
invention; 

15 Figure 4 is a flow diagram illustrating content distributor processing 

according to an embodiment of the present invention; 

Figure 5 is a flow diagram illustrating component vendor processing 
according to an embodiment of the present invention; 

Figure 6 is a flow diagram illustrating verification processing according to 
20 an embodiment of the present invention; 

Figure 7 is a diagram of a key hierarchy exhibiting revocation of a 
specific version according to an embodiment of the present invention; 

Figure 8 is a diagram of a key hierarchy exhibiting revocation of a 
specific version according to an embodiment of the present invention; 
25 Figure 9 is a diagram of a key hierarchy exhibiting revocation of a 

specific version according to an embodiment of the present invention; and 

Figure 10 is a diagram illustrating an exemplary system used by a 
content distributor, component vendor, or a content user according to an 
embodiment of the present invention. 

30 
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DETAILED DESCRIPTION 

An embodiment of the present invention is a method of revoking the 
authorization of software components using a key hierarchy in a loosely 
5 coupled content protection system. The software components may be used to 
render digital content on a content user system. Revocation of authorization 
means that the software components can no longer render the content for the 
user. 

Creating a robust end-to-end content distribution system requires the 

10 integrity and authenticity of trusted software components running on a user 
system to be determined before access to content is granted. Public key 
cryptography may be used as a basis for a key management system 
supporting content protection according to an embodiment of the present 
invention. When implementing a key management system as in the present 

15 invention for such a content protection system, several issues may be 
addressed. The security of a cryptographic system usually depends on 
maintaining the confidentiality of cryptographic keys. The present key 
management system is designed so as to minimize the risk of compromise of 
these sensitive keys. For example, the present system does not require one 

20 party to disclose sensitive key material to another party in order to express trust 
relationships between them. The key management system expresses 
relationships between multiple instances of each participant. For example, a 
content distributor may want to authorize software components that access the 
content from several different component vendors. Similarly, a component 

25 vendor may have relationships with several different content distributors. 

The key management system does not require large amounts of data to 
be transferred to convey authorization information. It is often useful to allow 
trust decisions to be transferred to other parties. For example, a content 
distributor may not want to certify a binary code image for each individual 

30 component. Instead, with the present invention a content distributor may 
delegate authorizations to a component vendor for all components developed 
by that vendor. Frequently, the trust relationships in the system are not known 
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a priori. The key management system of the present invention handles 
additions to the trust relationships over time. For example, if a selected digital 
content title is authorized to be rendered by a particular component (such as a 
first version of a secure codec, for example), the system does not fail if the 
5 user installs a different version of the codec (such as a second, newer version 
of the same secure codec). Finally, the key management system of the 
present invention expresses trust relationships that are no longer valid. These 
revocations may be expressed in a way that does not affect non-compromised 
components. For example, a content distributor may want to revoke trust of a 
10 particular version of a component, without revoking authorization of all 
components supplied by the content vendor who supplied the particular 
version. 

Reference in the specification to "one embodiment" or "an embodiment" 
of the present invention means that a particular feature, structure or 

15 characteristic described in connection with the embodiment is included in at 
least one embodiment of the present invention. Thus, the appearances of the 
phrase "in one embodiment" appearing in various places throughout the 
specification are not necessarily all referring to the same embodiment. 

Figure 1 is a diagram of an architecture of a key management and 

20 content protection system according to an embodiment of the present 
invention. A content creator 10 is an entity that authors the content. The 
content creator generates the digital content data 12, which may be stored in a 
file within a storage medium on a computer system or other digital processing 
system. For example, a content creator may record and mix music in a 

25 recording studio and store the music in a digital form on a storage medium. 
Generally, the content may be any multimedia content in a digital form, such as 
audio, video, images, text, music, movies, books, or other data. The content 
may be sent as either streaming or downloaded content. The format of the 
content may vary widely depending on the type of content. 

30 It is assumed that the content is created in a trusted environment. A 

content distributor system 14 is an entity that sells or distributes the content 
over a communications medium such as the Internet or other computer 
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network. The content distributor system may be controlled by the content 
owner or may be an authorized independent distributor or reseller of the 
content. Where the content is digitized music, the content distributor system 
may represent a music or record company that owns rights to the music or an 
5 authorized distributor, such as an on-line retailer. The content distributor 
system may use one or more server systems to distribute the content to one or 
more users on demand. In one embodiment, the content distributor system 
may employ a front server 16 that is coupled to a network 18 such as the 
Internet to handle queries from a client to obtain Web pages or content. In one 

1 0 embodiment, the protocol supported by the front server is Hyper Text Transport 
Protocol (HTTP), although other protocols may also be used. The content 
distributor system may also employ a back server 20, which is not coupled to 
an outside computer network such as the Internet. Because the back server is 
"stand-alone" and unconnected to the outside world, it may be considered to 

15 be more secure than the front server. In one embodiment, the back server 
may be a key management workstation used to create and store cryptographic 
keys employed in the key management system as described further herein. 

A content user system 22 is an entity that obtains and consumes the 
content distributed by content distributor system 14. The content user 

20 represents any party seeking to process digital content provided by content 
distributor system 14, including individual end users, businesses, and other 
organizations. Content user system 22 operates as a client in a client/server 
operating model in conjunction with the front server of content distributor 
system 14. The content user system sends requests for resources (e.g., Web 

25 pages, content) to the content distributor system over a network 18 (such as 
the Internet) and receives data in response to the requests. Network 18 may 
be any network or series of interconnected networks capable of transporting 
digital content from the content distributor system to one or more content user 
systems. For example, network 18 may be a local area network (LAN), a wide 

30 area network (WAN), the Internet, or a terrestrial broadcast network such as a 
satellite communications network. In one embodiment, the content user 
system comprises at least one of a personal computer (PC) system, an Internet 
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appliance, a set-top box, a handheld computer, a personal digital assistant 
(PDA), or other computing device. In other embodiments, the content user 
system may be coupled to the content distributor system through physical 
distribution of media, such as a floppy disk, a CD-ROM or a digital versatile 
5 disk (DVD). One or more component vendors 24 may be coupled to the 
network for distributing software components for use by a content user in 
rendering the content or otherwise interacting with the content. Component 
vendors may be entities independent of the content distributor and content 
creator who develop software for use in the content user system. In other 

10 embodiments, the component vendor may distribute components to the 
content user system using physical media. 

The key management and content protection system of embodiments of 
the present invention secure content persistently from the time a content user 
requests a document, book, video, or music to the point it is rendered on the 

15 content user system or loaded onto dedicated media players such as portable 
devices 26. Portable devices may include portable music players (e.g., MP3 
players), electronic book readers, or other portable content players. The 
content protection system uses a protected software module that hides critical 
code and keys from observation, detects tampering and provides a means of 

20 ongoing protection. In one embodiment, the protected software module 
comprises tamper resistant software. Content is decrypted only after 
authorizing its use, establishing that the user environment of the content user 
system 22 is trustworthy while the content is being rendered. The system 
allows content distributors to renew the security mechanisms, which makes it 

25 possible for content distributors to determine the appropriate level of protection 
by managing the frequency of renewal of trust. Content distributors may 
distribute many individually encoded security software components. Each 
content user system may receive an individually encoded component. Content 
distributors may renew the security software components over the network, 

30 helping to reduce the possibility of the components being compromised due to 
the frequent renewal. The effort needed to compromise the security 
mechanism is localized to the particular content being protected, so any 
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"hacking" effort has to be re-applied every time new content is delivered and 
consumed. 

The content protection system includes an electronic content distribution 
(ECD) system 28 resident on content user system 22 to control secure 
5 reception and playback of content received from content distributor system 14. 
The ECD system evaluates content requirements for authorized playback and 
content user system characteristics to determine if the content user system and 
its components may be trusted. ECD system 28 includes one or more unique, 
trusted software components that represent the interests of the content creator 

10 or content distributor. This software component, called an agent, acts a 
custodian of the content creator's interests. In one embodiment, the agent 30 
establishes itself as trusted via known tamper-resistant technologies and 
continuous integrity checking. It then extends the perimeter of trust by 
continuously checking the integrity of other software components such as plug- 

15 ins (e.g., codecs 32) and player 34. Because of this, attempts to tamper with 
the plug-ins, player or the agent may be detected by the agent 30, and further 
playback of content by player 34 may be halted. In another embodiment, the 
agent may operate in an isolated execution mode that provides a measure of 
security to deter tampering with the agent. In other embodiments, other 

20 methods for protecting the agent from tampering may be employed. The agent 
validates and enforces the conditions that must be fulfilled before the content 
can be consumed or rendered. These conditions can be anything that the 
content distributor chooses, consistent with the goal of balancing the protection 
of the content distributor's rights and the desire to give the content user a 

25 satisfying experience in obtaining and rendering the content. For example, the 
agent might check the content user system 22 for an electronic copy of a 
purchase receipt or verify a player identifier (ID) or user password. There may 
be many conditions an agent might verify on the content user system before 
allowing decryption and rendering of content to occur. After the agent has 

30 determined that the legitimate conditions for content usage have been met, the 
agent decrypts the content so it can be rendered by the player. To reduce the 
incentive for hacking attempts and minimize the amount of content that is 
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protected by the same security mechanism, the agent may be repeatedly 
renewed. 

Thus, agent 30 interacts with player 34, acting as a controller to 
determine if and when the content may be rendered. Player 34 may be any 
5 software component for processing of digital content. Examples of player 34 
for rendering music include RealJukebox™ available from RealNetworks, Inc. 
and WinAmp™ available from Nullsoft, Inc. Player 34 employs various other 
software components and plug-ins in order to process the content. Codecs 32 
may be used to decode and decompress the decrypted content. One or more 

10 licensed compliant modules (LCMs) 36 may be included in the system to 
interface between the player and portable devices 26. Each LCM may be 
provided by the manufacturer of the portable device to allow content to flow 
securely to the portable device from the player. One or more content 
protection agent service (CPAS) modules 38 may also be included to create an 

15 electronic "fingerprint" of the content user system. Any one or more of the 
components (player, codecs, LCMs, CPAS, and other modules) may be 
provided by the same or a different component vendor. 

The terms voucher, content voucher, object voucher, key voucher, and 
voucher package used herein may be defined as follows. A voucher may be a 

20 digitally signed document. By virtue of it being signed, a voucher's origin can 
be authenticated, its integrity verified, and the voucher may be non-reputable. 
There are several types of vouchers. A content voucher contains the "rules" for 
accessing a piece of digital content. For example, the voucher can specify the 
characteristics of a trusted software player such that content can only be 

25 played by a selected "trusted" software/hardware player combination. Content 
vouchers are generally created, signed, and distributed by content distributors, 
and they can be issued for every item of content if needed. An object voucher 
cryptographically describes a software module. A real world analogy of an 
object voucher is a driver license. Like a driver license, an object voucher 

30 contains a description of the software module but instead of using metrics like 
height, weight, etc., it uses a cryptographic hash of the software's runtime 
image. By using object vouchers, software developers can sign not only their 
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components, but also third party components distributed with their applications. 
A key voucher is used to introduce cryptographic public/private key pairs into a 
particular domain. Either implicitly or explicitly, a key voucher also grants the 
key pair certain rights, such as the right to sign content or object vouchers. 
5 This process is known as certification. A voucher package may be a data type 
that contains a "principal" voucher such as a content voucher, and optionally 
one or more key vouchers. These additional key vouchers form a "chain of 
trust" that models real world business relationships, such as that of content 
provider and content distributor. Thus, a content voucher package contains 

10 both the rules for accessing content as well as the certification of those rules. 
This allows for efficient access for verification in a way that is transparent to a 
software developer. 

When the content user system 22 requests content from the content 
distributor system 14, encrypted content 40 and content voucher 42 may be 

15 sent from the content distributor through the network to the content user. 
When the content is created and mastered by the content creator or the 
content distributor, a content voucher may be created which is associated with 
the content and which specifies usage rules for the content. In effect, the 
content voucher acts as a license for accessing the content. The content 

20 voucher may be used by the agent 30 in determining whether to allow player 
34 and other components access to the requested content. The content 
voucher may be assembled with other information to form a content voucher 
package to be transmitted to the content user system. 

In prior art systems, content protection and rendering were often 

25 implemented as a single, monolithic system. That is, a content distributor used 
one type of player which supported a single content format, often with a single 
security scheme. Once the monolithic security scheme was hacked or broken, 
all previously distributed content was at risk. Currently, there are many 
different players supporting different content formats, and the players interact 

30 with many different plug-ins provided by different component vendors. In such 
a scenario, in order to change a plug-in, one would like to not require the 
content user to return to the content distributor to get a new license for using a 
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new, authorized plug-in with previously authorized content. Additionally, a 
scheme that protects distributed content even when a single component is 
hacked would be valuable. Public key cryptography and a key management 
system according to an embodiment of the present invention may be used to 
5 achieve these goals. 

Multiple security keys may be used to authorize various content user 
system components based on the content voucher 42. However, in order to 
manage the distribution and protection of the keys, a novel key hierarchy is 
employed. The new key hierarchy allows the content creator and content 

10 distributor to decide for which components access is to be provided. Thus, 
with this key hierarchy system, a new key is used to authorize a new 
component. The key hierarchy supports revocation of trust of software on a 
component by component basis, as well as on a per content title basis. That 
is, authorization of each component and content title in a loosely coupled 

15 content protection system may be controlled individually. This provides a fine 
grained control of authorization and revocation. This provides significant 
advantages over prior art monolithic content protection systems. 

In embodiments of the present invention, the keys in the key hierarchy 
to be used for content protection may be created by the content distributor 

20 systems and component vendors. Various keys may be used to sign content 
vouchers and software components as will be discussed in further detail below. 
Embodiments of the present invention work in several stages: content 
distributor key setup, component vendor authorization, component vendor key 
setup, component authorization, content licensing, and verification. Tools used 

25 to generate cryptographic key pairs, to sign keys, and to create vouchers (e.g., 
digitally signed documents) are known. Various implementations of such tools 
may be used with the key hierarchy of the present invention. 

Figure 2 is a diagram of a key hierarchy according to an embodiment of 
the present invention. The diagram shows an example key hierarchy with three 

30 different vendors and multiple classes of components. It should be understood 
that this example is for illustrative purposes and that a key hierarchy according 
to an embodiment of the present invention may have any number of 
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components, levels and leaf nodes. The example key hierarchy of Figure 2 
may be best understood by reference to the architecture diagram of Figure 3 
and the flow diagrams of Figures 4 through 6 and accompanying discussion. 

Figure 3 shows the interconnections between content distributor system 
5 14, component vendor 24, and content user system 22. In addition, content 
distributor system 14 may be coupled to agent manufacturing service 44 to 
request generation of an agent 30 for installation at a content user system 22. 
Further reference will be made to Figure 3 below. 

Figure 4 is a flow diagram illustrating content distributor processing 

10 according to an embodiment of the present invention. Content distributor key 
setup may be as follows. At block 100, content distributor 14 creates a content 
voucher (CV) root key pair 60. The content voucher root key pair may be used 
as the root of trust for the key hierarchy and associated loosely coupled 
content protection system of embodiments of the present invention. The public 

15 key of this key pair may be embedded in a trusted checker program 31 that 
verifies the authenticity of software components on the content user system 22. 
The trusted checker program 31 may be included in agent 30 downloaded to 
the content user system within the ECD system 28. The private key of this key 
pair is of high value. It should be stored on a back server 20, and not on a 

20 front server 16 that is accessible to a public network such as the Internet, and 
thus at risk of unauthorized disclosure. At block 102, the content distributor 
creates a content voucher (CV) signing key pair 62. This key pair may be used 
on front server 16 of content distributor 14 to create content vouchers 42 at the 
time of content purchase. At block 104, the content distributor signs 61 the 

25 content voucher signing public key 62 with the content voucher root private key 
60. By signing the content voucher signing public key with the content voucher 
root private key, agent 30 on the content user system (which has the 
corresponding content voucher root public key) may verify that objects signed 
by the content voucher signing private key are actually from the content 

30 distributor. This exhibits the appropriate delegation of authority. If the content 
voucher root private key is kept secure, it may also be used to prepare 
revocation lists at a later point in time. 
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At block 106, the content distributor creates additional "component-root" 
key pairs. In another embodiment, the component root key pairs may be 
created by a trusted delegate of the content distributor. A component root key 
pair 46 may be referred to by content voucher 42. A component root key may 
5 be used to protect a particular component 48 provided to content user system 
22 by a component vendor 24. In the example key hierarchy shown in Figure 
2, there are two types of components that must be checked for authenticity and 
integrity (e.g., a codec and a content protection agent service (CPAS) module), 
so two component root key pairs may be created, a codec root key pair 64 and 

10 a CPAS root key pair 66. The private keys of these key pairs should be kept 
secure on the back server 20. A component root key 46 may be used as a root 
key for a particular class of components used on content user systems. Other 
keys based on this root key may comprise a key sub-hierarchy of the main key 
hierarchy described above. The component may be one of a codec, plug-in, or 

15 other software module providing desired functionality of use to the player. Note 
that the content distributor has created the content voucher root key pair 60, 
the content voucher signing key pair 62, and multiple component root key pairs 
64, 66. Once the content distributor has created the appropriate component 
root keys, third party component vendors may be authorized. 

20 Vendor authorization proceeds as follows. At block 108, a component 

vendor 24 creates it's own component vendor root key pair 50. The 
component vendor root key may be used as a root key for a vendor key 
hierarchy 52 which is a subset of the overall key hierarchy for the system. For 
example, in Figure 2, component vendor 1 creates component vendor 1 root 

25 key pair 68, component vendor 2 creates component vendor 2 root key pair 70, 
component vendor 3 creates component vendor 3 root key pair 72, and so on. 
Each component vendor has its own vendor key hierarchy for a particular 
component based on a selected component root key. These keys may be 
communicated to content distributor system 14 by arrangement with the 

30 component vendors. When a content distributor desires to authorize a 
particular component vendor as a trusted implementer of a particular 
component, at block 110 the content distributor signs a component vendor's 
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root public key received from a component vendor with a component root 
private key corresponding to the desired component. For example, in Figure 2, 
component vendor 1 root public key 68 may be signed 65 by codec root private 
key 64, component vendor 2 root public key 70 may be signed 71 by codec 
5 root private key 64, and component vendor root public key 72 may be signed 
73 by CPAS root private key 66, when content distributor desires to authorize 
component vendors 1, 2 and 3 as trusted for codecs and CPAS modules, 
respectively. The signed component vendor's root public key may be 
communicated back to the component vendor for future use by the component 
10 vendor in creating the vendor key hierarchy and object vouchers as discussed 
further below. 

Turning now to Figure 5, a flow diagram illustrating component vendor 
processing according to an embodiment of the present invention is shown. 
Each component vendor may set up it's own key hierarchy 52 to distinguish 

15 various classes of components that the vendor provides. This supports 
selective revocation at a later point in time. There may be an arbitrary number 
of levels of classes and versions of components. Individual vendors may not 
provide all necessary components to a given functionality, but may aggregate 
components from other sources. Component vendor key setup proceeds as 

20 follows. On a server system at a component vendor 24, a component vendor 
at block 112 creates a component class key pair for each category or class of 
component being manufactured or distributed by the vendor. In the example of 
Figure 2, component vendor 1 creates a codec class key pair 78. At block 114, 
the component vendor signs the component class keys with the component 

25 vendor's root private key. In the example of Figure 2, component vendor 1 
signs 76 the codec class public key 78 with component vendor 1 root private 
key 68. 

Component authorization proceeds as follows. When a component 
vendor desires to authorize a new component to work in the ECD system 
30 resident on a content user system 22, component vendor 24 at block 116 
creates a component version key pair 54. At block 118, the component vendor 
signs the component version public key with the component class private key. 
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This completes the formation of a hierarchy of keys that represents a particular 
component vendor's trusted product line. In the example of Figure 2, 
component vendor 1 signs 80 codec version 1.0 public key 82 with codec class 
private key 78, and component vendor 1 signs 86 codec version 2.0 public key 
5 88 with codec class private key 78. In another variation shown in Figure 2, 
component vendor 3 signs 90 CPAS version 1 .0 public key 92 with component 
vendor 3 root private key 72. This may be done when no class key is needed, 
for example, when the vendor only distributes a single component. 

Note that in the present key hierarchy, component vendors may sign 

10 and distribute new components and associated keys independently of the 
content distributor. That is, the content distributor does not have to take any 
actions supporting the distribution of components by the component vendor 
once the component vendor is authorized. At block 120, the component 
vendor creates an object voucher 56 and an object voucher package for a 

15 particular component being manufactured and distributed. The object voucher 
package contains information required to authenticate the component on the 
content user system. The information may include the public portions of the 
component vendor root key, the component class key, and the component 
version key. At block 122, the component vendor signs the object voucher for 

20 a component with a corresponding component version private key and a 
cryptographic hash of the component's runtime image. The cryptographic hash 
may be contained within the object voucher. In the example of Figure 2, 
component vendor 1 signs 94 codec voucher 96 with codec version 2.0 private 
key 88, and component vendor 3 signs 98 CPAS voucher 99 with CPAS 

25 version 1 .0 private key 92. As part of the signing process, the component 
vendor adds the chain of signed public keys from the hierarchy as additional 
vouchers to the object voucher packages. This enables content to be 
accessed by this particular component when verified. Thus, the object voucher 
package contains the content distributor component root public key, and the 

30 component version public key of the key hierarchy corresponding to the 
component object. The object voucher also contains the cryptographic 
signature of each public key, signed by its parent's private key (e.g., the 



16 



WO 02/10907 



PCT/US01/15007 



component version public key, signed by the component class private key). 
The object voucher 56 may be signed by the component vendor using an 
object signing tool 58. At some point in time prior to content distribution, the 
content user system obtains relevant software components such as player 34, 
5 codecs 32, LCMs 36, CPAS modules 38 from component vendors. In one 
embodiment, the components may be obtained over a network such as the 
Internet from each component vendor. When such software is installed, 
associated object vouchers 56 for each component created by the component 
vendors may also be included in the installation on the content user system. 

10 Content licensing proceeds as follows. At block 124, at the time a 

selected content title is vended or otherwise distributed by content distributor 
system 14 to content user system 22, the content distributor creates a content 
voucher package containing the content voucher 42 to specify all usage rules 
for that content title and one or more key vouchers. The usage rules may 

15 specify the components authorized to process the content. The key voucher 
may include the content voucher signing public key signed by the content 
voucher root private key. The component root public key 46 created at block 
106 may be inserted into the content voucher 42. The content voucher may be 
signed 63 by the content voucher signing private key 62. The content voucher 

20 package may then be communicated to the content user system. 

Verification processing proceeds as follows. Figure 6 is a flow diagram 
illustrating verification processing on the content user system according to an 
embodiment of the present invention. At the time of access to the content, a 
trusted checker module 31 within agent 30 on the content user system 

25 determines the trust of the other components 48 in the system based on 
content voucher 42 within the content voucher package and the object voucher 
56. At block 126, the checker 31 checks the integrity of the signed content 
voucher 42 using the content voucher signing public key 62 contained in the 
content voucher. At block 128, the checker module determines the trust of the 

30 content voucher signing public key 62 by checking the signature of the content 
voucher signing public key using the content voucher root public key 60 
embedded in the agent 30. At block 130, the checker parses the component 
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root keys 46 included in the content voucher 42. At block 132, the checker 
determines the integrity of a selected object voucher 56 corresponding to a 
component 48 using a component version public key 54 contained in the object 
voucher. 

5 At block 134, the trust of the component version public key 54 may be 

determined by checking the signatures of a chain of keys up to one of the 
component keys parsed from the content voucher at block 130. At block 136, 
the integrity of component 48 (e.g., a player, a codec, a plug-in, etc.) may be 
checked using information parsed from the corresponding object voucher 56. 

10 At block 138, when the integrity and authenticity of the component have been 
established using the key hierarchy of the present invention, the content user 
system may be allowed to decrypt and render the content using appropriate 
content protection keys contained in the content voucher. 

The configuration of the key hierarchy of the present invention provides 

15 at least several benefits for protecting content and components. The fact that 
the key hierarchy is based on public key cryptography allows authorizations to 
be completed without private key material being exposed. In addition, the use 
of the content voucher signing key by the content distributor ensures that a 
high value root key is not needed for an on-line transaction. This allows the 

20 root key to be stored and managed in a more secure environment. Since 
authorizations are expressed by a key hierarchy, flexibility is built into the 
system. Each content distributor can authorize multiple component vendors 
under this hierarchy. Similarly, a component vendor can support authorization 
of multiple classes of components and multiple versions of components in the 

25 vendor's portfolio. With respect to efficient data representations, as opposed 
to having an itemized list of authorized components, the use of the present key 
hierarchy allows authorization of potentially thousands of components to be 
expressed in very small data structures. 

Once the content distributor signs a component vendor root key, the 

30 component vendor can build and authorize components on behalf of the 
content distributor. This allows content distributors to remain out of the 
development life cycle of component vendors. Once the content distributor 
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signs the component vendor root key, the component vendor can continue to 
build new versions of components that will work with the existing content 
vouchers. This is in contrast to a prior art system where authorized 
components were explicitly listed in content vouchers. In that case, new 
5 content vouchers have to be issued to work with new components. 
Embodiments of the present invention provide a clear advantage in this regard. 

Regarding revocation, the fact that a component vendor creates a 
hierarchy of keys for a product line allows a content distributor to revoke a 
vendor at the component version, component class, or vendor level. If only a 

10 single key was used to sign all components from a vendor, a revocation would 
affect all components created by that vendor. Because the content voucher 
signing key is used to sign component class keys at content voucher creation 
time, the component certification key hierarchies can be disparate from the 
rights key hierarchy, and only bound together for a particular licensing 

15 transaction. This enables the content distributor to easily switch component 
class keys in the event of a key compromise, while instantaneously invalidating 
the compromised hierarchy. Replacing the component class key in a new 
content voucher achieves revocation of a previously valid component class key 
for new content, without the use of a revocation list. 

20 Revocation of authorization may be needed in any one of several 

instances. For example, if it is discovered that a malicious user has "broken" or 
"hacked" the content protection system, the content distributor may want to 
revoke access to distributed content. If any key distributed to a component 
vendor or content user system is accidentally disclosed, authorization of 

25 components affected by the disclosed key should be revoked. If a component 
root key is lost or disclosed, authorization of components corresponding to the 
component root key should be revoked. If a holder of a private key becomes 
malicious for some reason, authorization of components should be revoked. 

As discussed above, the signed content voucher specifies the content 

30 rights granted to the user system. The content voucher also specifies trusted 
components comprising a system in which content may be rendered. 
Components may be specified based on an inclusive model, meaning that any 
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component issued under a trusted key specified for that class of component 
(e.g., a component root key) is automatically trusted. With embodiments of the 
present invention, a component may be revoked by including a revocation list 
in the content voucher. The revocation list may contain information pertaining 
5 to one or more components which are no longer authorized. The revocation 
list may include at least one of the cryptographic hash of the component's 
binary image, the component root key associated with the components, or any 
keys in its key hierarchy, depending on the scope of the revocation desired. By 
doing this, at the time of determining authorization to access the content, the 

10 revocation list may be retrieved from the content voucher and checked against 
the key hierarchy used to sign a given component. If a key needed to verify 
authorization of the component is in the revocation list, authorization fails. 
Thus, embodiments of the present invention bind the revocation action to a 
single operating context within the content protection system and does not 

1 5 affect any other context. 

In embodiments of the present invention, at least three different levels of 
revocation may be supported. These three levels exhibit the flexibility of the 
present invention in supporting revocation of components. First, revocation of 
a specific version of a component may be supported. For example, a content 

20 distributor may revoke authorization of codec version 2.0 88 and associated 
codec voucher 96 as shown in Figure 7. Revocation of the key that was used 
to sign the codec voucher specifies that the agent executing on the content 
user system will not trust or use this component version from the component 
vendor. The agent instead will gracefully fail on its attempt to use the 

25 component, thereby preventing access to the content by the revoked 
component. As the example diagram shows, the key hierarchy for the codec 
component includes a content distributor's component root key (e.g., codec 
root key pair 64) that it uses to sigh the component vendor's root keys (e.g., 
component vendor 1 root key pair 68). The component vendor creates 

30 hierarchies according to the granularity of its products and versions. The more 
keys in the hierarchy, the better the granularity of revocation that may be 
achieved. 
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Second, revocation of a specific class of components may be 
supported. For example, a content distributor may revoke the class of codecs 
as shown in Figure 8. Revocation of the key that was used to sign this 
particular class of component provided by a specific component vendor 
5 specifies that the agent will not trust or use any component signed under this 
key. The agent instead will gracefully fail on its attempt to use any component 
of this class from the component vendor to access the content. 

Third, revocation of a specific component vendor may be supported. 
For example, a content distributor may revoke all components supplied by a 

10 particular component vendor as shown in Figure 9. Revocation of the key that 
was used by the component vendor to sign classes of components specifies 
that the agent will not trust or use any component signed under this key. The 
agent instead will gracefully fail on its attempt to use any component from this 
component vendor to access the content. 

15 Content distributor actions supporting revocation according to an 

embodiment of the present invention are shown in Figure 10. At block 200, a 
break may be detected in the content protection system. For example, the 
content distributor may discover or be informed that one or more private keys 
of the key hierarchy have been disclosed or "hacked". In such instances, the 

20 content distributor may communicate with the component vendor to identify 
specific component classes or versions of components to revoke. If a 
particular component vendor is considered to be suspect by the content 
distributor, all components supplied by the component vendor may be revoked. 
At block 202, the content distributor creates a list of revoked public keys from 

25 the key hierarchy due to the break. Since the key hierarchy is a tree, only the 
highest level key to be revoked need be specified (e.g., the root node of the 
sub-tree of all keys in the hierarchy to be revoked) instead of all such keys 
including all leaf nodes of the sub-tree in the hierarchy. Next, at block 204, the 
content distributor creates a data structure to embed in the content voucher. 

30 The data structure contains at least the revoked public keys. When the content 
distributor creates the content voucher at block 124 of Figure 5 prior to vending 
the content to the user, the content distributor may now insert the revocation 
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list into the content voucher. Hence, revocation of versions and classes of 
components, and component vendors, may be implemented, at least in part, by 
vending content to users. This action protects new content that is being 
distributed from earlier breaks in the security of the content protection system. 
5 When the checker within the agent is verifying authorization of a 

selected component as shown in the steps of Figure 6, the checker may now 
also check the revocation list contained in the content voucher at block 206 of 
Figure 10. If a particular component vendor public key, component class public 
key, or component version public key is in the revocation list, the checker 

10 causes a failure of the authorization process and the content may not be 
accessed by the selected component being checked. Otherwise, if the 
selected key is not on the revocation list, it is presumed that the component 
has not been revoked by the content distributor and the usual integrity 
verification and authentication operations relating to the content and object 

15 vouchers may be executed. 

Thus, the combination of the revocation list with the novel key hierarchy 
of the present invention allows a content distributor to selectively revoke 
components, classes of components, and component vendors. This invention 
provides at least several advantages. In current systems, selective revocation 

20 of software components is not supported. Current systems typically only 
support revocation of entire classes of devices. That is, in known public key 
infrastructures, revocations are issued in the form of signed lists, independent 
of any contextual binding. The present invention binds the revocation list 
directly to the usage context. This means that revocations are applied locally, 

25 in the context they were intended, rather than globally. With the present 
invention, components may be revoked when new content is delivered, without 
removing the user's existing rights to old content. This leads to a better user 
experience. It also enables a content distributor, collecting content from many 
content owners or creators, to enforce the usage specified by each content 

30 owner discretely. This feature cannot be enabled by a typical certificate 
revocation list of the prior art. The present invention also allows individual 
components to be revoked, without removing a component vendor's ability to 
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manufacture and certify components with their existing certified keys. As 
components are shown to expose security weaknesses, they can be selectively 
revoked for ail future content without removing the vendor's capability to fix 
vulnerabilities and release new products that work with new content without the 
5 need to get a new key or signature from the content distributor. The system 
also allows revocation to occur at various granularities, from a single 
component to a whole class of components. This allows content distributors to 
be as selective as they want to be in choosing components to work with on a 
per context basis. Also, because of the organization of this novel key hierarchy 
10 and the present invention, component vendors cannot revoke components 
issued by competing component vendors. The present invention also allows 
content owners to independently decide which components should be 
considered to be trustworthy for their content (i.e., they control the hierarchy for 
their content). 

15 In the preceding description, various aspects of the present invention 

have been described. For purposes of explanation, specific numbers, systems 
and configurations were set forth in order to provide a thorough understanding 
of the present invention. However, it is apparent to one skilled in the art having 
the benefit of this disclosure that the present invention may be practiced 

20 without the specific details. In other instances, well-known features were 
omitted or simplified in order not to obscure the present invention. 

Embodiments of the present invention may be implemented in hardware 
or software, or a combination of both. However, embodiments of the invention 
may be implemented as computer programs executing on programmable 

25 systems comprising at least one processor, a data storage system (including 
volatile and non-volatile memory and/or storage elements), at least one input 
device, and at least one output device. Program code may be applied to input 
data to perform the functions described herein and generate output 
information. The output information may be applied to one or more output 

30 devices, in known fashion. For purposes of this application, a processing 
system embodying the playback device components includes any system that 
has a processor, such as, for example, a digital signal processor (DSP), a 
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microcontroller, an application specific integrated circuit (ASIC), or a 
microprocessor. 

The programs may be implemented in a high level procedural or object 
oriented programming language to communicate with a processing system. 
5 The programs may also be implemented in assembly or machine language, if 
desired. In fact, the invention is not limited in scope to any particular 
programming language. In any case, the language may be a compiled or 
interpreted language. 

The programs may be stored on a removable storage media or device 

10 (e.g., floppy disk drive, read only memory (ROM), CD-ROM device, flash 
memory device, digital versatile disk (DVD), or other storage device) readable 
by a general or special purpose programmable processing system, for 
configuring and operating the processing system when the storage media or 
device is read by the processing system to perform the procedures described 

15 herein. Embodiments of the invention may also be considered to be 
implemented as a machine-readable storage medium, configured for use with 
a processing system, where the storage medium so configured causes the 
processing system to operate in a specific and predefined manner to perform 
the functions described herein. ( 

20 An example of one such type of processing system is shown in Figure 

I I , however, other systems may also be used and not all components of the 
system shown are required for the present invention. Sample system 400 may 
be used, for example, to execute the processing for embodiments of the key 
hierarchy and content protection system, in accordance with the present 

25 invention, such as the embodiment described herein. Sample system 400 is 
representative of processing systems based on the PENTIUM®II, PENTIUM® 

III, and CELERON™ microprocessors available from Intel Corporation, 
although other systems (including personal computers (PCs) having other 
microprocessors, engineering workstations, other set-top boxes, and the like) 

30 and architectures may also be used. 

Figure 1 1 is a block diagram of a system 400 of one embodiment of the 
present invention. The system 400 includes a processor 402 that processes 



24 



WO 02/10907 



PCT/US01/15007 



data signals. Processor 402 may be coupled to a processor bus 404 that 
transmits data signals between processor 402 and other components in the 
system 400. 

System 400 includes a memory 406. Memory 406 may store 
5 instructions and/or data represented by data signals that may be executed by 
processor 402. The instructions and/or data may comprise code for performing 
any and/or all of the techniques of the present invention. Memory 406 may 
also contain additional software and/or data (not shown). A cache memory 408 
may reside inside processor 402 that stores data signals stored in memory 
10 406. 

A bridge/memory controller 410 may be coupled to the processor bus 
404 and memory 406. The bridge/memory controller 410 directs data signals 
between processor 402, memory 406, and other components in the system 
400 and bridges the data signals between processor bus 404, memory 406, 

15 and a first input/output (I/O) bus 412. In this embodiment, graphics controller 
413 interfaces to a display device (not shown) for displaying images rendered 
or otherwise processed by the graphics controller 413 to a user. 

First I/O bus 412 may comprise a single bus or a combination of multiple 
buses. First I/O bus 412 provides communication links between components in 

20 system 400. A network controller 414 may be coupled to the first I/O bus 412. 
In some embodiments, a display device controller 416 may be coupled to the 
first I/O bus 412. The display device controller 416 allows coupling of a display 
device to system 400 and acts as an interface between a display device (not 
shown) and the system. The display device receives data signals from 

25 processor 402 through display device controller 416 and displays information 
contained in the data signals to a user of system 400. 

A second I/O bus 420 may comprise a single bus or a combination of 
multiple buses. The second I/O bus 420 provides communication links 
between components in system 400. A data storage device 422 may be 

30 coupled to the second I/O bus 420. A keyboard interface 424 may be coupled 
to the second I/O bus 420. A user input interface 425 may be coupled to the 
second I/O bus 420. The user input interface may be coupled to a user input 
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device, such as a remote control, mouse, joystick, or trackball, for example, to 
provide input data to the computer system. An audio controller 427 may be 
coupled to the second I/O bus for handling processing of audio signals through 
one or more loudspeakers (not shown). A bus bridge 428 couples first I/O 
5 bridge 412 to second I/O bridge 420. 

Embodiments of the present invention are related to the use of the 
system 400 as a content distributor, component vendor, or content user 
system. According to one embodiment, such processing may be performed by 
the system 400 in response to processor 402 executing sequences of 

10 instructions in memory 404. Such instructions may be read into memory 404 
from another computer-readable medium, such as data storage device 422, or 
from another source via the network controller 414, for example. Execution of 
the sequences of instructions causes processor 402 to execute content 
protection processing according to embodiments of the present invention. In 

15 an alternative embodiment, hardware circuitry may be used in place of or in 
combination with software instructions to implement embodiments of the 
present invention. Thus, the present invention is not limited to any specific 
combination of hardware circuitry and software. 

The elements of system 400 perform their conventional functions in a 

20 manner well known in the art. In particular, data storage device 422 may be 
used to provide long-term storage for the executable instructions and data 
structures for embodiments of the content protection system in accordance 
with the present invention, whereas memory 406 is used to store on a shorter 
term basis the executable instructions of embodiments of the content 

25 protection system in accordance with the present invention during execution by 
processor 402. 

While this invention has been described with reference to illustrative 
embodiments, this description is not intended to be construed in a limiting 
sense. Various modifications of the illustrative embodiments, as well as other 
30 embodiments of the invention, which are apparent to persons skilled in the art 
to which the inventions pertains are deemed to lie within the spirit and scope of 
the invention. 
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CLAIMS 



What is claimed is: 

1 

2 1 . A method of selectively revoking authorization of software components 

3 by a content distributor in a content protection system comprising: 

4 creating a list of at least one key corresponding to at least one component 

5 for which authorization is to be revoked, the at least one key belonging to a key 

6 hierarchy used in the content protection system, the key hierarchy comprising a 

7 tree having a component vendor root key corresponding to a component vendor 

8 as a root of the tree; and 

9 inserting the list into a content voucher, the content voucher specifying 
10 rules for access to selected content by the at least one component. 

11 

1 2. The method of claim 1 , wherein the at least one key is a leaf of the tree, 

2 the at least one component being resident on a user system in the content 

3 protection system. 
4 

1 3. The method of claim 1 , further comprising sending the content voucher 

2 to the user system. 

3 

1 4. The method of claim 3, further comprising causing the list in the content 

2 voucher to be checked by a software module on the user system to verify 

3 authorization of the at least one component and revoking authorization of the at 

4 least one component for accessing the content when the at least one key is on the 

5 list. 



6 
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1 5. The method of claim 4, wherein when the list includes the component 

2 vendor root key, revoking authorization of all classes and all components 

3 distributed by the component vendor. 
4 

1 6. The method of claim 5, wherein the key hierarchy comprises at least 

2 one class key corresponding to a selected class of components, the class key 

3 being a root of a sub-tree of the tree, and wherein when the list includes a class 

4 key, revoking authorization of all components of the class distributed by the 

5 component vendor. 
6 

1 7. The method of claim 4, further comprising revoking authorization of a 

2 component when the list includes a corresponding component key. 
3 

1 8. The method of claim 4, further comprising revoking authorization of a 

2 component when the list includes a hash of the component. 
3 

1 9. An article comprising: a storage medium having a plurality of machine 



2 readable instructions, wherein when the instructions are executed by a processor, 

3 the instructions provide for selective revocation of authorization of a software 

4 component by a content distributor in a content protection system, the instructions 

5 including creating a list of at least one key corresponding to at least one 

6 component for which authorization is to be revoked, the at least one key belonging 

7 to a key hierarchy used in the content protection system, the key hierarchy 

8 comprising a tree having a component vendor root key corresponding to a 

9 component vendor as a root of the tree; and inserting the list into a content 

10 voucher, the content voucher specifying rules for access to selected content by 

1 1 the at least one component. 
12 
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1 10. The article of claim 9, wherein the at least one key is a leaf of the tree, 

2 the at least one component being resident on a user system in the content 

3 protection system 
4 

1 11. The article of claim 10, further comprising instructions for sending the 

2 content voucher to the user system. 
3 

1 12. The article of claim 1 1 , further comprising instructions for causing the 

2 list in the content voucher to be checked by a software module on the user system 

3 to verify authorization of the at least one component and revoking authorization of 

4 the at least one component for accessing the content when the at least one key is 

5 on the list. 



6 



1 13. The article of claim 12, wherein when the list includes the component 

2 vendor root key, further comprising instructions for revoking authorization of all 

3 classes and all components distributed by the component vendor. 
4 

1 14. The article of claim 13, wherein the key hierarchy comprises at least 

2 one class key corresponding to a selected class of components, the class key 

3 being a root of a sub-tree of the tree, and wherein when the list includes a class 

4 key, further comprising instructions for revoking authorization of all components of 

5 the class distributed by the component vendor. 
6 

1 15. The article of claim 12, further comprising instructions for revoking 

2 authorization of a component when the list includes a corresponding component 

3 key. 
4 

1 16. The article of claim 12, further comprising instructions for revoking 

2 authorization of a component when the list includes a hash of the component. 
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3 

1 17. A content protection system providing selective revocation of software 

2 components comprising: 

3 a key hierarchy comprising a tree having a component vendor root key 

4 corresponding to a component vendor as a root of the tree and at least one key as 

5 a leaf of the tree corresponding to at least one component for which authorization 

6 is to be revoked, the at least one component being resident on a user system in 

7 the content protection system; 

8 a content voucher specifying rules for access to selected content by the at 

9 least one component, the content voucher including a list having the at least one 

10 key corresponding to the at least one component for which authorization is to be 

11 revoked; and 

1 2 a content distributor to create the content voucher and send the content 

13 voucher to the user system. 
14 

1 18. The system of claim 17, further comprising a software module resident 

2 on the user system to check the list in the content voucher to verify authorization 

3 of the at least one component and revoke authorization of the at least one 

4 component for accessing the content when the at least one key is on the list. 
5 

1 19. The system of claim 18, wherein when the list includes the component 

2 vendor root key, the software module revokes authorization of all classes and all 

3 components distributed by the component vendor. 
4 

1 20. The system of claim 19, wherein the key hierarchy comprises at least 

2 one class key corresponding to a selected class of components, the class key 

3 being a root of a sub-tree of the tree, and wherein when the list includes a class 

4 key, the software module revokes authorization of all components of the class 

5 distributed by the component vendor. 
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21 . The system of claim 20, wherein the software module comprises a 
tamper-resistant module. 
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